Completed functionality for `admin check` command #5348

kevinrr888 · 2025-02-21T15:49:44Z

New checks for admin check command

Implemented SYSTEM_CONFIG check:
- Checks ZooKeeper locks for Accumulo server processes
- Checks ZooKeeper table nodes
- Checks that the WAL metadata in ZooKeeper is valid
Added new SERVER_CONFIG check:
- Checks that all configured properties are valid
- Checks that required properties are present in the config
Added new tests in AdminCheckIT for SYSTEM_CONFIG and SERVER_CONFIG. Added failing test cases for all checks.
Updated description for admin check run command functionality #4892. This describes all the checks thus far for the new accumulo admin check command. See this for the complete functionality of the command.
Considered adding check to MetadataConstraints to ensure tablets reference files that actually exist (i.e., in MetadataConstraints.validateDataFileMetadata, check that stf.getPath() exists in HDFS). This would make sure the file exists before the mutation is ever written and would also check that it exists when we run the admin check command for metadata (root metadata, root table, and metadata table): see MetadataCheckRunner.checkColumns(). However, this led to a ComprehensiveIT test failure, so I assume the file may not always exist before the metadata for it is written...
Deleted CheckServerConfig (run via accumulo check-server-config) as the new accumulo admin check run SERVER_CONFIG will inherently do the same checks. Maybe we don't want to completely get rid of this check yet. Maybe it would be better to have the check just output that the check has moved under accumulo admin check?
There were a couple other existing check commands that I originally considered moving under this new admin command (CheckAccumuloProperties and CheckCompactionConfig), however, their usage is specifically to check a file irrespective of any running Accumulo instance, so I did not feel it would make sense to move these under the new admin command.

This PR along with #4957 closes #4892

- Implemented SYSTEM_CONFIG check: - Checks ZooKeeper locks for Accumulo server processes - Checks ZooKeeper table nodes - Checks that the WAL metadata in ZooKeeper is valid - Added new SERVER_CONFIG check: - Checks that all configured properties are valid - Checks that required properties are present in the config - Added new tests in `AdminCheckIT` for SYSTEM_CONFIG and SERVER_CONFIG. Added failing test cases for all checks. - Deleted CheckServerConfig (run via `accumulo check-server-config`) as the new `accumulo admin check run SERVER_CONFIG` will inherently do the same checks.

kevinrr888 · 2025-02-21T15:52:30Z

test/src/main/java/org/apache/accumulo/test/AdminCheckIT.java

@@ -34,19 +35,29 @@
 import java.util.Set;
 import java.util.TreeMap;
 import java.util.function.Supplier;
-import java.util.regex.Pattern;



General comment about AdminCheckIT: considered changing from ConfigurableMacBase to SharedMiniCluserBase for this test from suggestion of @dlmarion. Prior to these new changes, SharedMiniClusterBase was sufficient and much faster, but some of these tests now do damage to the MAC to test for failure cases of the checks (e.g., deleting essential files, messing with metadata), so stuck with ConfigurableMacBase

kevinrr888 · 2025-02-21T15:54:25Z

server/base/src/main/java/org/apache/accumulo/server/conf/CheckServerConfig.java

-import com.google.auto.service.AutoService;
-
-@AutoService(KeywordExecutable.class)
-public class CheckServerConfig implements KeywordExecutable {


I deleted CheckServerConfig since now this is checked through this SERVER_CONFIG check: the ServerContext object is constructed the same (see ServerUtilOpts) and we end up calling context.getConfiguration() in the SERVER_CONFIG check, so the same checks are done with a few additions. Maybe we don't want to completely get rid of this check yet. Maybe it would be better to have the check just output that the check has moved under accumulo admin check?

kevinrr888 · 2025-02-21T15:55:29Z

...base/src/main/java/org/apache/accumulo/server/util/checkCommand/ServerConfigCheckRunner.java

+    // there are many properties that should be set (default value or user set), identifying them
+    // all and checking them here is unrealistic. Some property that is not set but is expected
+    // will likely result in some sort of failure eventually anyway. We will just check a few
+    // obvious required properties here.
+    Set<Property> requiredProps = Set.of(Property.INSTANCE_ZK_HOST, Property.INSTANCE_ZK_TIMEOUT,
+        Property.INSTANCE_SECRET, Property.INSTANCE_VOLUMES, Property.GENERAL_THREADPOOL_SIZE,
+        Property.GENERAL_DELEGATION_TOKEN_LIFETIME,
+        Property.GENERAL_DELEGATION_TOKEN_UPDATE_INTERVAL, Property.GENERAL_IDLE_PROCESS_INTERVAL,
+        Property.GENERAL_LOW_MEM_DETECTOR_INTERVAL, Property.GENERAL_LOW_MEM_DETECTOR_THRESHOLD,
+        Property.GENERAL_PROCESS_BIND_ADDRESS, Property.GENERAL_SERVER_LOCK_VERIFICATION_INTERVAL,
+        Property.MANAGER_CLIENTPORT, Property.TSERV_CLIENTPORT, Property.GC_CYCLE_START,
+        Property.GC_CYCLE_DELAY, Property.GC_PORT, Property.MONITOR_PORT, Property.TABLE_MAJC_RATIO,
+        Property.TABLE_SPLIT_THRESHOLD);


any other important ones I left out? Any I shouldn't have included?

Not a change for this PR, but wondering if this should be pushed to the validation code of each property. For example could we attempt to do something like the following in addition to the code that goes through the defined props above. Thinking if a props validation fails on null or empty string then its "required" and should be set. Looking at some of the important props, like instance.volumes their types would need change from something besides STRING that is more specific, which would be a good general change to make (would be good to have specific type to do validation for instance volumes and that could include not accepting empty string).

for(var prop : Property.values()) { var value = config.get(prop); if (!Property.isValidProperty(prop.getKey(), value)) { log.warn("Invalid property (key={} val={}) found in the config", prop, value); } }

If the rest of the code worked like this, then would not need this list here.

As the code is currently written it loops over all the props the loop in the prev comment may not work well because the get method replaces w/ the default value when not present.

In general it seems like it would be best to move the concept of a required property into the Property class in some form. Then the entire system could react appropriately when a required property is not present and is requested. For now a list in this class seems fine.

I experimented w/ validating the volume prop in #5365 based on the exploration done as part of this.

This sounds like a good idea to me. There are a lot of PropertyType.STRING when a String isn't really what the property is. PropertyType exists to check that the property is valid; setting the PropertyType to STRING is just a way to ignore this validation. I wonder if it would be best for a 1 to 1 mapping Property to PropertyType. This would probably be overkill though, another idea could be to analyze the PropertyTypes that are always valid. From briefly looking, PropertyType.PATH, PropertyType.STRING, PropertyType.URI are always valid. I don't think any properties should always be valid. Those that are PropertyType.STRING could probably be given a more appropriate existing PropertyType or a new one. PATH and URI could have validation.

In addition to this, can analyze all properties, determine if they are required or not, and change the validation:

Properties that are not required could accept empty string, null, or a valid value (where validity is well defined)

Properties that are required could only accept a valid value

Like you said, for this PR, can just push this list of required properties into Property. Maybe for now/in this PR this list of required props is only accessed/checked in this admin check. Might be a bit of a scope creep to start checking this list elsewhere in the code. Could do it in follow on.

Definitely want to avoid any scope creep in this PR. Identified some areas that need improvement based on this work, we can open follow on issues or PRs for those.

Could leave the list as is in the PR. For follow on issues, do we need two issues? One for addressing the STRING types and another for somehow representing and documenting required props in the Property.java?

I think either would be fine, but it might be easier as just one issue. There would be overlap in these changes so might be hard to split up/work on as two separate issues/PRs. For example, instance.volumes would need to be a required property (which would be tied to validation in it's PropertyType) and would need to be moved away from PropertyType.STRING

kevinrr888 · 2025-02-21T15:57:02Z

...er/base/src/main/java/org/apache/accumulo/server/util/checkCommand/RootTableCheckRunner.java

  public Set<ColumnFQ> requiredColFQs() {
    return Set.of(MetadataSchema.TabletsSection.TabletColumnFamily.PREV_ROW_COLUMN,
        MetadataSchema.TabletsSection.ServerColumnFamily.DIRECTORY_COLUMN,
-        MetadataSchema.TabletsSection.ServerColumnFamily.TIME_COLUMN,
-        MetadataSchema.TabletsSection.ServerColumnFamily.LOCK_COLUMN);
+        MetadataSchema.TabletsSection.ServerColumnFamily.TIME_COLUMN);
  }


Do the required col FQs and col fams in RootTableCheckRunner, RootMetadataCheckRunner, and MetadataTableCheckRunner look correct now? If these look good, since these are all equivalent now, can push these up to no longer override and return the same thing...

Yeah those look good.

kevinrr888 · 2025-02-21T15:58:08Z